home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 22
/
Aminet 22 (1997)(GTI - Schatztruhe)[!][Dec 1997].iso
/
Aminet
/
util
/
dtype
/
MidiDT.lha
/
MidiDT
/
Future.readme
next >
Wrap
Text File
|
1997-10-05
|
3KB
|
77 lines
About the midi.datatype future:
Preface:
I am having not much time to spend for programming and I have some
other projects, too, so, if you are a programmer, I need your help.
And I do not know all about midi, so I need some help to do the
final design. If you even want to take over the whole project,
please contact me.
What is to do:
Well, there are still some small improvements to be done like:
* Send reset before starting playing
* Make use of some special features of datatypes.library V45
* Create a prettier control panel
* etc.
but I think that the BIG thing should be done first:
To make loading/saving useable and allow the use of subdatatypes,
there is a need to specify a nice memory representation of midi
music files.
Having this it will require to write code to load and save midi files
and the midi player needs to be fully rewritten.
Memory representation of midi music:
The most common midi file format "Standard Midi File" (SMF) consists
of byte streams divided into tracks by something that looks similar
to an IFF format. These midi streams are good for sequential (serial)
access and do need very little memory, but they fail miserably when
trying to be accessed randomly. Random access however is required by
editors and by players that can skip to a specifyed song location.
So it should be considered to transform this midi byte stream into
a tree of structures and arrays to allow easy editing and random
accessing of it.
What programs can make use of this memory representation ?
* Midi editors for loading/saving midi files. It is important that the
memory representation allows easy editing of the midi stream.
* Midi file ananlyzers for loading midi files.
* Midi music generators (for example a drummachine or algorythmic tunes)
for playing and saving midi files.
* Programs that print midi melodies on paper for loading.
* midi.datatype subclasses for loading/saving non-SMF files. Special
care must be taken to ensure, that all important midi file formats
(and even those that appear in future) can be converted into this
memory representation.
* The internal player of midi.datatype, but external players do not
need it, since they can make use of the internal player even if they
have their own GUI.
What about music modules ?
One difference between midi music and Protracker like music modules is
that midi uses synthetic sounds as instruments and modules use sampled
sounds as instruments being part of the module. If this would be the
only difference, everything would be fine and converting between them
would only be a matter of selecting the right instruments.
The instruments of modules are another problem, since many samples that
are used cannot be found on a midi synthesizer. A further big difference
is the effect section, which is very different (even between different
module formats).
And last but not least the way data is stored is totally different. Midi
uses byte streams with explicit timing information whereas modules use
a data array, called pattern, with implicit timing information. Explicit
timing information allows more precise timing and can save memory.
So can there be a music.datatype combining midi and modules ?
If somebody has enough time to design and program this, I think yes.
As an alternative a separate module.datatype could be designed with
the same interface for playing.